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1.0  INTRODUCTION 

This  chapter  explains  the  purpose  of  the  convention,  and  the  scope 
of  the  guidance  and  provides  an  explanation  of  how  to  use  the 
convention. 

1.1  PURPOSE  OF  THE  CONVENTION 

The  convention  provides  general  guidance  on  the  implementation 
of  American  National  Standards  Institute  (ANSI)  Accredited  Stand¬ 
ards  Committee  (ASC)  X12  electronic  data  interchange  (EDI) 
standards  within  automated  information  systems  (AIS)  and  on 
information  interchange  procedures  that  require  the  collection, 
reporting,  and/or  exchange  of  data  needed  to  perform  defense 
missions. 

1.2  SCOPE 

The  guidance  presented  here  may  be  used  by  organizational  ele¬ 
ments  of  the  DoD  community  and  by  non-DoD  organizations  that 
exchange  data  with  the  DoD  community  in  the  course  of  their 
business  relationships. 

The  DoD  community  encompasses  the  Military  Services,  Organiza¬ 
tions  of  the  Joint  Chiefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  referred  to  as  the  DoD  Components). 

Non-DoD  organizations  include  (a)  non-Govemment  organiza¬ 
tions,  both  commercial  and  nonprofit;  (b)  Federal  agencies  of  the 
United  States  Government  other  than  DoD;  (c)  local  and  state 
governments;  (d)  foreign  national  governments;  and  (e)  interna¬ 
tional  government  organizations. 

The  draft  convention  published  in  this  document  is  for  trial  use 
and  comment.  DoD  Components  must  submit  to  the  Office  of  the 
Under  Secretary  of  Defense  (Acquisition  and  Technology),  Com¬ 
puter-aided  Acquisition  and  Logistics  Support  and  Electronic  Data 
Interchange  [OUSD  (A  &  T)  CALS/EDI]  their  data  requirements 
that  are  not  covered  in  this  convention  as  soon  as  possible,  as 
indicated  in  Chapter  2.0,  Section  2.1. 

13  RESPONSIBLE  ENTITY 

(Reserved) 

1.4  HOW  TO  USE  THE  IMPLEMENTATION 
CONVENTION 

The  main  topics  and  structures  of  this  document  conform  to  the 
EDI  Implementation  Reference  Manual  Guidelines  document  that 
was  developed  by  a  task  group  of  the  subcommittee  on  education 
and  implementation  of  the  ASC  XI 2.  The  purpose  of  having 
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agreed-upon  topics  and  structure  is  to  facilitate  reference  by  the 
many  industry  and  DoD  personnel  who  are  involved  in  implement¬ 
ing  the  uniform  standards  for  electronic  interchange  of  business 
transactions. 

1.4.1  Conventions,  Standards,  and  Guidelines 

The  terms  conventions,  standards,  and  guidelines  are  used 
throughout  this  document  and  are  defined  as  follows: 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  ASC  X12  standards.  Conventions  define  what  is 
included  in  a  specific  implementation  of  an  ASC  X12  standard. 

•  Standards  are  the  technical  documentation  approved  by 
ASC  X12;  specifically,  transaction  sets,  segments,  data  ele¬ 
ments,  code  sets,  and  interchange  control  structure.  Standards 
provide  the  structure  for  each  ASC  X12  document. 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI.  Guidelines 
are  intended  to  provide  assistance  and  should  not  be  your  sole 
source  of  information. 

1 .4.1 .1  Who  Develops  the  Conventions? 

Conventions  result  from  a  joint  effort  by  business,  technical,  and 
EDI  ASC  X12  standards  experts.  The  business  data  requirement 
is  defined,  a  transaction  set  is  selected,  and  the  data  requirement 
is  then  identified  with  data  elements  in  the  transaction  set.  A 
convention  is  usually  developed  before  any  computer  EDI  systems 
development  work  and  serves  as  a  design  document  when  the 
development  process  begins. 

1.4.1 .2  Why  Use  a  Convention? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  XI 2  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  that  task  is  contained  in  the  convention 
document.  Users  who  follow  the  convention  will  create  a  transac¬ 
tion  set  that  all  DoD  users  understand. 

1.4. 1.3  Who  Needs  a  Convention? 

System  analysts  and  application  programmers  who  plan  to  create 
or  read  ASC  X12  transactions  use  a  convention  to  aid  in  interface 
software  design.  The  convention  will  help  the  programmer  and 
analyst  identify  where  their  application  data  requirement  should  be 
carried  in  an  ASC  X12  transaction  set. 

1. 4.4.4  Can  I  Develop  a  Convention? 

Conventions  already  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization’s  EDI  coordinator  at  the  start  of  an  EDI  project. 
If  you  find  no  conventions  for  the  business  practice  you  are  about 
to  implement,  your  EDI  coordinator  should  contact  the  CALS 
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Evaluation  and  Integration  Office.  See  Chapter  2.0,  Maintenance , 
Section  2.1  for  the  point  of  contact. 

1 .4.2  Documentation  of  Conventions 

Conventions  are  adopted  from,  and  are  intended  to  be  in  confor¬ 
mance  with,  ANSI  ASC  X12  standards  or  ASC  X12  Draft  Stand¬ 
ards  for  Trial  Use  (DSTU). 

1. 4.2.1  Transaction  Set 

Figure  1.4-1  provides  an  example  of  a  transaction  set  table.  The 
transaction  set  defines  information  of  business  or  strategic  sig¬ 
nificance  and  consists  of  a  transaction  set  header  segment,  one  or 
more  data  segments  in  a  specified  order,  and  a  transaction  set 
trailer  segment.  The  actual  ASC  X12  standard  as  it  appears  in  the 
official  ASC  X12  standards  manual  is  presented  on  the  right  side 
of  the  page.  That  standard  also  includes  both  syntax  notes  and 
comments.  The  specific  DoD  usage  designator  is  presented  on  the 
left  side  of  the  page. 

The  designation  “N/U”  stards  for  “not  used”  and  appears  in  the 
left  column  if  DoD  does  not  use  the  specific  segment.  A  page 
number  will  appear  if  the  segment  is  used. 

1 .4.2.2  Transaction  Sat  Segment 

Figure  1.4-2  is  an  example  of  a  transaction  set  segment. 

DoD  usage  is  specified  on  the  left  side  of  the  page.  For  identifier 
(ID)-type  data  elements,  acceptable  code  values  are  listed  on  the 
right  side  of  the  page  under  the  definitions  of  the  element. 

DoD  notes,  reflecting  how  the  convention  is  to  be  used  appear  on 
the  right  side  of  the  page  at  the  segment  level  or  the  data  element 
level. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  DoD-specific  segment 
directory  section  of  the  convention.  For  ASC  X12  usage,  see  the 
definitions  in  X12.6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  are  defined  by  ASC  X12. 

•  Optional 

Optional  data  elements  are  used  at  the  discretion  of  the  sending 
party  or  are  based  upon  mutual  agreement  between  trading 
partners. 

•  Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules  but  are  required  by  DoD  decision. 

•  Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  DoD,  but  the  industry  recommends 
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•34  ■ 

APPLICATION  ADVICE 

ANSI  A  SC  X13  VERSION  RELEASE  003010000 

824  Application  Advice 

This  standard  provides  the  format  and  establishes  the  data  contents  of  the 
Application  Advice  Transaction  Set  1824)  within  the  context  of  an  Electronic 

i 

Oata  intercnange  (EDI)  environment 

This  transaction  set  provides  the  ability 

to  report  tne  results  of  an  application  system  $  data  content  edits  of 

transaction  sets  The  results  of  editing  transaction  sets  can  be  reported  at  the 
functional  group  and  transaction  set  level,  m  either  coded  or  tree-form  format 

it  is  designed  to  accomodate  the  business  need  of  reporting  the  acceptance, 
reiection  or  acceptance  with  change  of  any  transaction  set.  The  Application 
Advice  should  not  be  used  m  place  of  a  transacted  set  designed  as  a 
specific  response  to  another  transaction  set  (e  g.,  purchase  order 
acknowledgement  sent  m  response  to  a  purchase  order). 
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Figure  1.4-1  Example  of  a  Transaction  Set  Table 
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Mandatory 


Segment:  BGN  Boginning  Segment 
Lovol:  Header 

Loop:  _ 

Usage:  Mandatory 
Max  Use:  i 

Purpose:  To  indicate  trie  beginning  of  a  transaction  set 
Syntax:  if  BGN05  is  used.  BGN04  is  required 
Comments:  1.  BGN02  is  the  Transaction  Set  Reference  Number 

2.  BGN03  is  trie  Transaction  Set  Date 

3.  BGN 04  is  the  Transaction  Set  Time 

4.  BGN05  is  the  transacton  set  time  qualifier 
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Figure  1.4-2  Example  of  a  Transaction  Set  Segment 
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their  use  to  facilitate  EDI.  Most  companies  in  the  industry 
are  e»  pected  to  use  this  data  element. 

•  Not  Used 

“Not  Used”  data  elements  are  those  that  DoD  does  not  use. 

•  Conditional 

Conditional  data  elements  depend  on  the  presence  of  other  data 
elements  in  the  transaction  set. 
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2.0  MAINTENANCE 


This  chapter  describes  the  procedures  for  maintaining  the  DoD 
conventions.  It  also  presents  a  section  on  version/release  timing 

2.1  MAINTAINING  CONVENTIONS 

( Reserved} 

2.2  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version"  of  a  standard  is  critical  to 
the  successful  interchange  of  information.  Each  participant  must 
be  able  to  send  and  receive  the  same  version  to  ensure  the  accuracy 
of  the  information  exchanged. 

The  version  is  transmitted  as  a  12-character  code  in  the  Functional 
Group  Header  segment  (GS)  in  Data  Element  #4h0,  Ver¬ 
sion/Release/Industry  ID.  This  12-character  code  is  used  by 
ASC  X12  as  follows: 

Position  C  patent 

1-3  Version  number 

4-5  Release  level  of  version 

6  Subrelease 

7-12  DoD/lndustry  or  Trade  Association  ID 

ASC  X12  assigns  the  codes  in  Positions  1  through  6. 

The  version  number  (001,  002,  003.  etc.)  will  change  only  after  an 
official  public  review  cycle  leads  to  republication  of  a  new 
American  National  Standard. 

The  release  level  of  each  new  major  version  (Positions  4-6  in  the 
Functional  Group  Header)  will  begin  at  “000”  and  increased  by  1 
for  each  new  ASC  X12  approved  publication  cycle,  usually  once 
a  year.  The  fourth  and  fifth  characters  designate  the  release  and 
the  sixth  character  designates  the  subrelease. 

The  DoD  Industry  Trade  Association  ID  (Position  7-12)  is  used 
to  identify  conventions.  For  this  suffix,  DoD  will  use  “DoD_" 
with  the  10th  character  identifying  successive  publications.  The 
11th  and  12th  characters  may  be  used  by  the  Military  Departments 
or  Defense  agencies. 

DoD  conventions  for  using  ASC  X12  standards  are  published 
annually.  Conventions  developed  for  each  release  will  be  main¬ 
tained  for  4  years.  Military  Services  and  DoD  agencies  will 
determine  which  release  to  use  on  the  basis  of  business  need  but 
will  not  use  any  release  more  than  4  years  old  without  approval 
by  the  OUSD  (A  &  T)  CALS/EDI. 
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3.0  DoD  CONVENTIONS  FOR  USING 
ASC  X12  TRANSACTION  SETS 


This  chapter  defines  the  DoD  transaction  set  conventions.  It 
includes  the  instructions  for  implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  applicable  codes. 

3.1  INTRODUCTION 

The  power  of  the  ASC  X12  standard  is  in  its  building  block 
concept,  which  standardizes  the  essential  elements  of  business 
transactions.  The  concept  is  analogous  to  a  "standard  bill  of 
materiels  and  the  construction  specifications,”  which  gives  the 
architect  flexibility  in  what  can  be  designed  with  standardized 
materiels  and  procedures.  The  EDI  system  designer,  like  the  ar¬ 
chitect,  uses  the  ASC  X12  standards  to  build  business  transactions 
that  are  often  different  because  of  their  function  and  yet  utilize  the 
ASC  X12  standards.  The  “bill  of  materiels  and  the  construction 
specification”  of  ASC  X12  are  the  standards  found  in  the  published 
technical  documentation. 

ASC  X12.3  -  The  Data  Element  Dictionary  specifies  the  data 
elements  used  in  the  construction  of  the  segments  that  comprise 
the  transaction  sets  developed  by  ASC  XI 2. 

ASC  XI  2.5  -  The  Interchange  Control  Structure  provides  the 
interchange  control  segment  (also  called  an  envelope)  of  a  header 
and  trailer  for  the  electronic  interchange  through  a  data  transmis¬ 
sion;  it  also  provides  a  structure  to  acknowledge  the  receipt  and 
processing  of  the  envelope. 

ASC  XI  2.6  -  The  Application  Control  Structure  defines  the  basic 
control  structures,  syntax  rules,  and  semantics  of  EDI. 

ASC  XI 2. 22  -  The  Data  Segment  Directory  provides  the  defini¬ 
tions  and  specifications  of  the  segments  used  in  the  construction 
of  transaction  sets  developed  by  ASC  X12. 

The  DoD  convention  in  Section  3.4  conforms  to  the  above  stand¬ 
ards,  and  each  transaction  set  is  a  complete  document  to  the  extent 
possible.  For  further  clarification  of  acronyms,  abbreviations,  and 
codes,  refer  to  ASC  XI 2  published  technical  documentation.  For 
copies,  contact  either  the  OUSD  (A  &  T)  CALS/EDI  or  the  Data 
Interchange  Standards  Association,  Inc.,  Suite  355,  1800  Diagonal 
Road,  Alexandria,  VA  22314. 

3.2  CONTROL  SEGMENTS 

In  addition  to  the  communication  control  structure,  the  EDI  structure 
provides  the  standards  user  with  multiple  levels  of  control  to  ensure 
data  integrity.  It  does  so  by  using  header  and  trailer  control  segments 
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designed  to  identify  uniquely  the  start  and  end  of  the  interchange 
functional  groups  and  transaction  sets.  The  relationship  of  these 
control  segments  is  shown  in  Figure  3.2-1.  Control  Segment 
specifications  are  defined  in  Section  3.2.2. 

3.2.1  Description  of  Use 

The  interchange  header  and  trailer  segments  surround  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions: 

•  Define  the  data  element  separators  and  data  segment  ter¬ 
minators 

•  Identify  the  sender  and  receiver 

•  Provide  control  information 

•  Allow  for  authorization  and  security  information. 

The  Interchange  Acknowledgment  Segment  is  used  to  acknowledge 
one  interchange  header  and  trailer  envelope  where  the  envelope 
surrounds  one  or  more  functional  groups.  (No  acknowledgment  is 
made  for  the  interchange  acknowledgment.) 

The  interchange  control  number  value  in  the  acknowledgment 
(TA1  segment)  is  the  same  as  that  for  the  ISA  segment  that  is 
being  acknowledged.  The  control  number  serves  as  a  link  between 
the  interchange  header  and  trailer  and  the  acknowledgment  of  that 
header  and  trailer. 

The  interchange  acknowledgment  does  not  report  any  status  on  the 
functional  groups  contained  in  the  interchange  and  is  separate 
from  the  communication  system’s  error  procedures. 

The  preparer  of  the  interchange  header  and  trailer  indicates  the 
level  of  acknowledgment  in  Data  Element  113,  Acknowledgment 
Requested.  If  an  acknowledgment  is  requested,  then  the  recipient 
must  return  an  acknowledgment.  If  not  requested,  none  should  be 
given. 

The  interchange  acknowledgment  control  segments  are  placed  after 
the  interchange  header  and  before  the  first  functional  group  or 
before  the  interchange  trailer  if  there  are  no  functional  groups. 


Control  segments  are  standard  for  all  implementation  conventions 
produced  for  the  Department  of  Defense.  Some  codes  associated 
with  individual  data  elements  within  the  control  segments  are 
unique  to  the  individual  transaction  set.  Others,  identify  the  ANSI 
version  and  release  in  which  the  convention  is  written. 
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Segment:  ISA  Interchange  Control  Header 

Purpose:  To  start  and  identify  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

PES- _ ELEMEKT  NAME _ _ _ _ ATTHWOTES 

ISA01  101  Authorization  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Authorization  Information. 

00  No  Authorization  Information  Present  (No  Meaningful  Information  in  102) 

ISA02  102  Authorization  Information  M  AN  10/10 

Information  used  for  additional  identification  or  authorization  of  the  sender  or  the 
data  in  the  interchange.  The  type  of  information  is  set  by  the  Authorization 
Information  Qualifier. 

Implementation  Note: 

If  no  authorization  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA03  103  Security  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Security  Information. 

01  Password 

ISA04  104  Security  Information  M  AN  10/10 

This  is  used  for  identifying  the  security  information  about  the  sender  or  the  data 
in  the  interchange.  The  type  of  information  is  set  by  the  Security  Information 
Qualifier. 

Implementation  Note: 

An  agreed  upon  password.  If  no  security  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA05  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  {VAN). 

ISA06  106  Interchange  Sender  ID  M  ID  15/15 

Identification  code  published  by  the  sender  for  other  parties  to  use  as  the 
receiver  ID  to  route  data  to  them.  The  sender  always  codes  this  number  in  the 
sender  ID  element. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  IS  AOS  and 
coordinated  with  the  VAN. 

ISA07  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defin  \ 
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Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

Mandatory  ISA08  107  Interchange  Receiver  ID  M  ID  15/15 

Identification  code  published  by  the  receiver  of  the  data.  When  sending,  it  is 
used  by  the  sender  as  their  sending  ID,  thus  other  parties  sending  to  them  will 
use  this  as  a  receiving  ID  to  route  data  to  them. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 

Mandatory  ISA09  108  Interchange  Date  M  DT  6/6 

Date  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  YYMMDD 

Mandatory  ISA10  109  Interchange  Time  M  TM  4/4 

Time  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  HHMM 

Mandatory  ISA11  110  Interchange  Control  Standards  Identifier  M  ID  1/1 

Code  to  identify  the  agency  responsible  for  the  control  standard  used  oy  the 
message  that  is  enclosed  by  the  interchange  header  and  trailer. 

U  U.S.  EDI  Community  of  ASC  XI 2,  TDCC,  and  UCS 

Mandatory  ISA12  111  Interchange  Control  Version  Number  M  ID  5/5 

This  version  number  covers  the  interchange  control  segments  and  the  functional 
group  control  segments. 

00303  Draft  Standard  for  T rial  Use  Approved  for  Publication  by  ASC  XI 2  Procedures 
Review  Board  Through  October  1992 

Code  Value  Implementation  Note: 

Version  ID  as  defined  or  agreed  upon  by  the  trading  partners. 

Mandatory  ISA13  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Mandatory  ISA14  113  Acknowledgment  Requested  M  ID  1/1 

Code  sent  by  the  sender  to  request  an  interchange  acknowledgment. 

0  No  Acknowledgment  Requested 
1  Interchange  Acknowledgment  Requested 

Mandatory  ISA15  114  Test  Indicator  M  ID  1/1 

Code  to  indicate  whether  data  enclosed  by  this  interchange  envelope  is  test  or 
production. 

P  Production  Data 
T  Test  Data 
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Mandatory 


Code  Value  Implementation  Note: 

Assigned  by  translation  software. 

ISA  16  IIS  Subelement  Separator  M  AN  1/1 

This  is  a  field  reserved  for  future  expansion  in  separating  data  element 
subgroups.  (In  the  interest  of  a  migration  to  international  standards,  this  should 
he  different  from  the  data  element  separator). 

Implementation  Note: 

Use  character 
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Segment:  GS  Functional  Group  Header 

Purpose:  To  indicate  the  beginning  of  a  functional  group  and  to  provide  control 
information 


Syntax:  The  data  interchange  control  number  (GS06)  in  this  header  must  be 
identical  to  the  same  data  element  in  the  associated  Functional  Group 
Trailer  (GE02). 

Comment:  A  functional  group  of  related  transaction  sets,  within  the  scope  of  XI 2 

standards,  consists  of  a  collection  of  similar  transaction  sets  enclosed  by 
a  functional  group  header  and  a  functional  group  trailer. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

■IF  DAT* 

PIS _ ELEMFMT  NAMt _ ATTWIDUTtS 

GS01  479  Functional  Identifier  Code  M  ID  2/2 

Code  identifying  a  group  of  application  related  Transaction  Sets. 

Implementation  Note: 

Choose  the  code  value  appropriate  to  the  information  content  of  the  functional  group.  See  X12  Dictionary  for 
source  code  list. 

SP  Specifications/Technical  Information  (841) 

GS02  142  Application  Sender’s  Code  M  AN  2/15 

Code  identifying  party  sending  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  For  increased  security,  rton-DoD  code  should  differ  from  that 
used  in  ISA06. 


Mandatory 


GS03  124  Application  Receiver’s  Code  M  AN  2/15 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC ).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  For  increased  security,  non-DoD  code  should  differ  from  that 
used  in  ISA08. 


Mandatory 


GS04  373  Date 

Date  sender  generated  a  transaction  set. 


M  DT  6/6 


Mandatory 


Mandatory 


Mandatory 


GS05  337  Time  M  TM  4/6 

Time  expressed  in  24-hour  clock  time. 

GS06  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 

Implementation  Note: 

Assigned  by  translation  software. 

GS07  455  Responsible  Agency  Code  M  ID  1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard. 

X  Accredited  Standards  Committee  XI 2 


DI23  •  3.0.10 


BASELINE  AS  OF:  JULY  9, 1993 


DEPARTMENT  OP  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


001  •  CONTROL  SEGMENTS  841  SOLICITATION  TECHNICAL  DOCUMENTATION 

GS  •  FUNCTIONAL  GROUP  HEADER  ANSI  ASC  X12  VERSION/RELEASE  003030DOD 


Mandatory 


Cc  ’’  Value  Implementation  Note: 

Indicates  that  an  ANSI  XI 2  standard  is  being  transmitted 

GS08  480  Version/Release/Industry  ID  Code  M  ID  1/12 

Code  indicating  the  version,  release,  subrelease  and  industry  identifier  of  the  EDI 
standard  being  used.  Positions  1-3,  version  number ;  positions  4-6,  release  and 
subrelease  level  of  version;  positions  7-12,  industry  or  trade  association  identifier 
(optionally  assigned  by  user). 

003030  Draft  Standards  Approved  by  ASC  XI 2  Through  October  1992. 

Code  Value  Implementation  Note: 

Code  value  agreed  to  by  trading  partners.  SeeXI2  Dictionary  for  source  code  list. 
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Segment:  GE  Functional  Group  Trailer 

Purpose:  To  indicate  the  end  of  a  functional  group  and  to  provide  control 
information 

Syntax:  The  data  interchange  control  number  (GE02)  in  this  trailer  must  be 

identical  to  the  same  data  element  in  the  associated  Functional  Group 
Header  (GS06). 


Comment:  The  use  of  identical  data  interchange  control  numbers  in  the  associated 
functional  group  header  and  trailer  is  designed  to  maximize  functional 
group  integrity.  The  control  number  is  the  same  as  that  used  in  the 
corresponding  header. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF  DATA 

PIS _ ELEMEKT  KAMI _ _ ATTRflTTES 

GE01  97  Number  of  Transaction  Sets  Included  M  NO  1/6 

Total  number  of  transaction  sets  included  in  the  functional  yioup  or  interchange 
(transmission)  group  terminated  by  the  trailer  containing  this  data  element. 

Implementation  Note: 

Assigned  by  translation  software. 

GE02  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  control  number  of  the  preceding 
GS06  control  number. 
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Segment:  IEA  Interchange  Control  Trailer 

Purpose:  To  define  the  end  of  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  cc  ntrol  segments. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

Rif  DATA 

OES. _ ELPdtHT  NAME _ ATTHaUTES 

IEA01  116  Number  of  Included  Functional  Groups  M  NO  1/5 

A  count  of  the  number  of  functional  groups  included  in  a  transmission. 

Implementation  Note: 

Assigned  by  translation  software. 

IEA02  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  number  that  occurs  in  ISAJ3. 
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EXAMPLE  -  SPECIFICATIONS/TECHNICAL  INFORMATION 
841  TRANSACTION  SET  (SOLICITATION  TECHNICAL  DOCUMENTATION) 


ASC  X12  EDI  FORMAT  DEHMI1IQM 

SE  *84 1*0001  n/1  This  is  an  841  transaction  set  with  a  control  number  of  0001. 

SPI*92*TN*841STD001****00*SD*02  n/1  The  data  provided  in  this  transaction  set  are  classified 

government  confidential  (Code  92).  This  is  an  original 
transmission  (Code  00)  of  data  in  support  of  an  RFQ  (Code 
SD)  with  a  transaction  set  reference  number  (Code  IN)  of 
841STD001.  The  data  also  have  a  commercial  security 
protection  level  of  company  confidential  (Code  02). 

REF*KS*N0001993Q2468  n/1  The  solicitation  (Code  KS)  number  to  which  the  data  in  this 

transaction  set  pertains  is  N0001993Q2468. 

The  date  of  the  solicitation  (Code  999)  is  June  15, 1993. 

The  reference  number  (Code  TN)  of  this  transaction  set  is 
841STD001. 

The  date  of  this  transaction  set  (Code  097)  is  June  16, 1993. 

The  unique  reference  number  (Code  ZZ)  of  die  transaction  set 
to  which  the  data  in  this  transmission  pertain  is  841RFQ2468. 

The  date  of  the  transaction  set  (Code  368)  is  June  16, 1993. 

The  buying  activity  (Code  BY)  as  specified  by  DoDAAC  (Code 
10)  N00Q19. 

The  selling  party  (Code  SE)  as  specified  by  CAGE  code  (Code 
33)  B1234. 

The  configuration  manager  (Code  DG)  as  specified  by  the 
DoDAAC  (Code  10)  N56789. 

PER*IC*Nick  Nolte*EM*EMTEL123  n/1  The  point  of  contact  (Code  IC)  at  the  buying  activity  is  Nick 

Nolle.  His  electronic  mafl  address  (Code  EM)  is  EMTEL123. 

HL*1**A*1  n/1  This  is  the  first  iteration  of  the  HL  Loop,as  specified  by  the 

number  1.  It  has  no  parent  The  hierarchical  level  is  the 
assembly  (Code  A).  It  has  subordinate  levels. 

SPI*90*DD*12E221 1-877***F  n/1  The  data  being  provide  is  government  Don-classified  (Code  90). 

It  is  a  Engineering  Data  List  (Code  DD)  with  a  reference 
number  of  12E2211-877.  It  is  released  for  quotation  (Code  F). 


DTM*993*930615  n/1 
REF*TN*841STD001  n/1 

DTM*097*930616  n/1 
REF*ZZ*841RFQ2468  n/1 

DTM*368*930616  n/1 
N1*BY**10*N00019  n/1 

N1*SE**33*B1234  n/1 

N1*DG**10*N56789  n/1 
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LIN**F7*FB111A*FSM680010839*PD* 
Panel,  Ground  Check*ZZ*FJ  n/1 

The  end  item  application  (Code  F7)  is  FBI  11  A.  The  NSN 
(Code  FS)  is  1680010839.  The  part  number  description  (Code 

PD)  is  Panel,  Ground  Check.  The  applicable  Data  Tech 
organization  code  (Code  ZZ)  is  FJ. 

N1*33**10*N78961  n/l 

The  Data  Tech  entity  (Code  33)  is  as  specified  by  DoDAAC 
(Code  10)  N78961. 

N1*ZE**33*B1234  n/l 

The  Manufacturer  (Code  ZE)  is  as  specified  by  CAGE  code 
(Code  33)  B1234. 

EFI*90***3.3*CAT*3.2*MCAD*2.8*FISH 

••EDLn/1 

The  data  being  pro  Tided  in  the  BIN  segment  are  government 
non -classified  (Code  90).  It  was  created  using  an  application 
program  known  as  CAT,  Version  33.  The  transfer  format 
used  is  MCAD,  Version  33.  The  file  was  compressed  using  the 
FISH  program.  Version  2£.  The  name  of  the  file  containing 
this  data  is  EDL. 

BIN*28745* _ n/l 

The  binary  data  transmitted  is  28745  octets  in  length. 

HL*2*1*U*1  n/l 

This  is  the  second  iteration  of  the  HL  Loop  as  specified  by  tBe 
number  2.  Its  parent  is  HL  1.  The  hierarchical  level  is  the 
subassembly  (Code  U).  It  has  subordinate  levels  (Code  1). 

SPI*92*DG*12E22U***A***©2  n/l 

Drawing  (Code  DG)  number  12E2211  b  classified  government 
confidential  (Code  92).  It  b  an  approved  version  (Code  A)  and 
has  a  commercial  protection  requirement  of  company 
confidential  (Code  02). 

RDT*E*AY*007*92L215  n/l 

This  b  revision  (Code  E)  "AY",  with  an  effective  date  (Code 

007)  of  December  15, 1992. 

LIN**PD*Panel  Assembly  n/l 

The  item  description  (Code  PD)  b  Panel  Assembly. 

£Fi*92**9N*3J*TnmkCad*3J*MIL-R- 
28002*3 J*TRIM*AH*DRAW  n/l 

The  data  provided  are  classified  government  confidential 
(Code  92).  The  security  technique  is  encryption  (Code  9N).  It 
was  created  using  an  application  program  known  as 

Trunk  Cad,  Version  3.3.  The  transfer  format  used  b  Raster 
(MLL-R-28002),  Version  3.2.  The  fife  was  compressed  using 
the  TRIM  program,  Version  33.  The  drawing  size  to  be 
plotted  b  8.5  inches  x  11.0  inches  (Code  AH).  The  name  of 
the  file  containing  these  data  b  DRAW. 

BIN*105678* _ n/l 

The  binary  data  transmitted  are  105678  octets  in  length. 

HL*3*2*I*0  n/l 

This  b  the  third  iteration  of  the  HL  Loop  as  specified  by  the 
number  3.  Its  parent  is  HL  2.  The  hierarchical  level  is  the 
item  (Code  I).  There  are  no  subordinate  leveb  (Code  0). 

SPI*90*ZZ*LM12E2211*Bill  of  Material 
n/l 

The  item  number  being  provide  (Code  ZZ),  LM12E2211,  b  a 

Bill  of  Material  and  b  government  non -classified  (Code  90). 
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EFl*90***3.0*CAT*3J*MCAD*2.8* 
MOYER**MATL  n/1 


BIN*76543* _ n/1 

ST*30*0001 


The  date  prorided  are  government  non -classified  (Code  90). 

It  was  created  using  an  application  program  known  as  CAT, 
Version  3.0.  The  transfer  format  need  is  MCAD,  Version  32. 
The  file  was  compressed  using  the  Moyer  program.  Version 
2.8.  The  name  of  the  file  containing  this  data  is  MATL. 

The  binary  data  transmitted  are  76543  octets  in  length. 

This  transaction  set,  whose  control  number  is  0001,  contains  30 
segments. 
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841  Specifications/Technical  Information 

This  Draft  Standard  tor  Trial  Use  contains  the  format  and  establishes  the  data  contents  of  the 
Specifications/TechnicaJ  Information  Transaction  Set  (841)  for  use  within  the  context  of  an 
Electronic  Data  Interchange  (EDI)  environment  The  transaction  set  can  be  used  to  transmit 
specifications  or  technical  information  between  trading  partners  It  can  be  used  to  allow  EDI 
trading  partners  the  ability  to  exchange  a  complete  or  partial  technical  descnption  of  a  product, 
process,  service,  etc  over  the  same  path  as  any  other  EDI  transaction  The  detail  area  can 
include  graphic,  text,  parametric,  tabular,  image,  spectral,  or  audio  data.  A  transmission  indudes 
identification  information  to  assist  the  receiver  in  interpreting  and  utilizing  the  information 
included  in  the  transaction. 

Further  action  as  a  consequence  of  the  receipt  and  initial  processing  of  the  specification  or  other 
technical  data  may  or  may  not  require  human  intervention.  The  transmission  and  receipt  of  the 
data  may  require  private  agreement  between  the  trading  partners  to  automate  the  receipt  of  the 
data. 

The  total  transaction  must  be  in  the  general  form  of  all  ASC  XI 2  transactions  so  that  an  EDI 
computer  system  will  be  able  to  automatically  recognize  it  as  a  Specification/Technical 
Information  Transaction  Set  and  pass  it  on  for  processing  of  the  data  itself  The  transaction  set 
is  not  media  dependent. 

The  detail  area  of  the  Specificationfiechnical  Information  Transaction  Set  provides  a  structure 
which  allows  for  the  exchange  of  a  variety  of  specification  information.  For  example,  if  the 
transaction  contains  information  describing  a  complete  assembly,  it  would  be  necessary  to 
include  the  assembly  model,  the  models  for  each  of  the  individual  parts,  and  the  associated 
specifications.  In  the  case  of  a  process  it  may  be  necessary  to  transmit  the  specification  of  the 
product  along  with  the  specifications  of  the  process  and  raw  materials  This  transaction  set  can 
also  be  linked  to  other  transaction  sets. 

This  transaction  set  is  not  limited  to  a  specific  transmission  protocol  and  uses  other  standards  as 
applicable  where  they  do  not  conflict  with  these  requirements  for  specification  transaction 

Implementation  Note 

This  draft  implementation  convention  is  designed  to  provide  a  prospective  bidder  with  the  technical 
documentation  required  to  submit  a  bid  in  response  to  an  840  transaction  set,  (Request  for  Quotation).  This 
84 1  transaction  set  is  a  companion  to  an  840  transaction  set.  The  BQT  segment  at  the  Header  level  of  the 
840  transaction  set  will  tie  a  solicitation  number  to  the  REF  segment  at  the  Header  level  of  this  841 
transaction  set.  Reference  segments  in  both  transaction  sets  can  contain  unique  </  ansaction  set  control 
numbers  to  lie  the  transaction  sets  together  if  necessary. 
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SEG.  ID  NAME _ 

ST  Transaction  Set  Header 

LOOPfO-SW  “ 

SPI  Specification  Identifier 

RDT  Revision  Date/Time 

NTE  Note/Special  Instruction 

XI  Export  License 

X2  Import  License 

X7  Customs  Information 

GOV  Military  Standard  1840-A  Record  Definition 
LOOP  ID  -  SP1/REF 
REF  Reference  Numbers 


REQ.  DES.  MAX  USE 

M  1 


LOOP  REPEAT 
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>1 
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*1 
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o 

1 

Additional  Name  Information 

o 

2 

Address  Information 

0 

2 

Geographic  Location 

o 

1 
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o 

>1 

Administrative  Communications  Contact 

0 

>1 

le  2 
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DECIDES 

WAX  USE 

LOOP  REPEAT 

LOOP  ID -HL 
Hierarchical  Level 


M 


*1 


LOOP  ID  -  HL/SPt 

>1 

Specification  Identifier 

O 

1 

Revision  Date/Time 

o 

>1 

Item  Identification 

o 

1 

Name 

o 

>1 

Message  Text 

o 

>1 

LOQPlD'HUPiD 

>1 

Product/Item  Description 

o 

1 

Packaging  Description 

o 

>1 

Quantity 

o 

>1 

Measurements 

o 

>1 

Unit  Detail 

o 

>1 

Location 

o 

1 

Paperwork 

o 

*1 

LOOP  ID  -  HL/PID/PKG 

*1 
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o 

1 

Measurements 

o 

>1 

ttWID-HUREF 

>1 

Reference  Numbers 

o 

1 

Date/Time  Reference 

o 

>1 

Administrative  Communications  Contact 
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>1 

LOOP  ID  *  HL/LX 

>1 
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o 

1 

Measurements 

o 
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Date/Time  Reference 
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>1 

Reference  Numbers 
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>1 

LOOP  ID  -  HUEF1 

»1 

Electronic  Format  Identification 

0 

1 

Military  Standard  1840-A  Record  Definition 

0 

>1 

Binary  Data 

0 

>1 

LOOP  ID  »  HUC© 

*1 

Characteristic/Class  ID 

0 

1 

Unit  Detail 

o 

1 

Test  Method 

o 

>1 
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o 
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Conditional  Sampling  Sequence 

o 
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N/U  210 
N/U  220 

N/U  230 
N/U  240 
N/U  250 

N/U  260 
N/U  270 
N/U  280 


Sampling  Parameters  tor  Summary  Statistics 
Message  Text 


LOOP  ID  •  HUCJD/MEA 

Measurements 
Date/Time  Reference 
Reference  Numbers 


LOOP  10  •  HUCID/STA 

Statistics 

Date/Time  Reference 
Reference  Numbers 


LOOPIO-HL/atUCSF 
Conditional  Sampling  Frequency 
Loop  Header 

LOOP  ID  f  HUCID/CSF/CJD 

Characteristic/Class  ID 
Measurements 
Statistics 
Loop  Trailer 


LOOP  ID  ♦  HL/C10/EFI 

Electronic  Format  Identification 
Military  Standard  1840-A  Record  Definition 
Binary  Data 


PAGE*  PCS.* 


Table  3 


SEG.  ID  NAME 


Transaction  Set  Trailer 


RECL  DES.  MAX  USE 


LOOP  REPEAT 


NOTES: 

2/010  To  be  meaningful,  at  least  one  of  the  SPI,  PID,  REF,  MEA,  EFI  or  CID  loops 
must  be  present  with  each  occurence  of  the  HL  loop. 

2/020  The  HL  segment  may  be  used  to  define  the  hierarchical  relationship  of  product-re¬ 
lated  specifications  reported  in  the  associated  HL  loop.  Product-related  specifica¬ 
tions  may  refer  to  the  product  in  its  entirety  or  to  subunits  of  the  product.  For 
example,  if  the  top  level  refers  to  an  assembly,  the  second-level  HL  segment 
may  refer  to  parts  or  subassemblies  of  the  top  assembly.  This  pattern  may  be 
repeated  as  often  as  required. 

2/170  The  CID  segment  may  be  used  to  define  either  a  general  class  of  properties, 
such  as  physical  properties,  or  an  individual  property  within  a  class.  The  CID 
loop  allows  the  user  the  ability  to  define  specifications  such  as  the  properties  of 
the  item  or  class,  the  environmental  conditions  under  which  the  specifications 
apply,  the  test  methods  to  be  used,  and  other  parameters  related  to  properties 
within  the  current  HL  hierarchical  level. 

2/201  The  sampling  sequence  specified  in  the  CSS  segment  will  take  precedence  over 
any  other  sampling  rate  (PSD03,  PSD09,  SPS06,  CSF02,  and  CSF03)  from  the 
point  the  CSS01  event  occurs  until  the  specified  sequence  is  completed. 

2/201  If  no  other  sampling  is  specified,  then  only  the  sampling  indicated  in  this  segment 
is  performed  when  the  CSS01  event  occurs. 
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2/282  The  sampling  rate  specified  is  the  CSF  segment.  It  would  take  precedence  over 
the  normal  sampling  rate  specified  in  PSD03  while  the  conditions  of  the  CSF  seg¬ 
ment  are  satisfied,  but  would  NOT  take  precedence  over  the  sampling  sequence 
activated  by  the  proposed  CSS  segment. 

2/282  If  no  other  sampling  rate  is  specified,  then  the  only  sampling  indicated  in  the  CSF 
segment  is  performed  while  the  CSF  conditions  are  met.  Sampling  will  cease 
when  the  conditions  are  no  longer  met. 

2/282  Conditional  values  specified  in  DE  740  (Range  Minimum)  will  be  interpreted  as 
"greater  than  or  equal  to  this  value."  Values  specified  in  DE  741  (Range  Maxi¬ 
mum)  will  be  interpreted  to  mean  “less  than  or  equal  to  this  value.” 

2/282  Repetitions  of  the  CSF  loop  allow  several  frequency  changes  (and  the  conditions 
that  would  trigger  those  changes)  to  be  specified. 

2/282  If  the  conditions  are  such  that  several  CSF  values  are  activated  at  the  same 
time,  the  value  with  the  highest  sampling  rate  shall  prevail. 

2/284  Either  the  MEA  segment  or  the  STA  segment  must  occur,  but  not  both. 

2/284  The  CID  loop  within  the  CSF  loop  is  used  to  specify  the  conditions  that  will  trig¬ 
ger  activation  of  the  conditional  value  in  the  CSF  segment. 

2/284  Repetitions  of  the  CID  loop  will  have  an  implied  logical  AND  between  the  condi¬ 
tions  set  in  each  iteration. 

2/285  The  elements  of  the  CID  segment  identify  the  conditional  property.  If  the  property 
is  a  measurement  from  within  the  manufacturing  process  of  a  plant  environment, 
rather  than  the  product,  the  segment  also  identifies  the  location  where  the  meas¬ 
urements  are  to  be  observed. 

2/286  If  the  condition  is  based  on  single  test  measurements,  the  MEA  segment  is  used 
to  specify  the  units  of  measure,  and  the  open  or  closed  numeric  range  of  the  con¬ 
ditional  test. 
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Segment:  ST  Transaction  Set  Header 
Level:  Header 


Mandatory 


Loop:  _ 

Usage:  Mandatory 
Max  Use:  1 

Purpose:  To  indicate  the  start  of  a  transaction  set  and  to  assign  a  control  number 

Semantic:  The  transaction  set  identifier  (ST01 )  used  by  the  translation  routines  of 
the  interchange  partners  to  select  the  appropriate  transaction  set 
definition  (e.g.,  810  selects  the  invoice  transaction  set). 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

RCF.  DATA 

DCS _ CLEMENT  NAME _ _ _ ATTTttDUTCS  _ 

ST01  143  Transaction  Set  Identifier  Code  M  ID  3/3 

Code  uniquely  identifying  a  Transaction  Set. 

841  X12.51  Specifications/Technical  Information 

ST02  329  Transaction  Set  Control  Number  M  AN  4/9 

Identifying  control  number  that  must  be  unique  within  the  transaction  set 
functional  group  assigned  by  the  originator  for  a  transaction  set 

Implementation  Note: 

This  unique  number  is  assigned  by  the  originator  of  the  transaction  set  or  by  the  originator's  application 
program.  This  same  number  is  carried  in  SE02. 
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Segment:  SPI  Specification  Identifier 
Level:  Header 


Mandatory 


Loop:  SPI  Repeat:  >1 
Usage:  Mandatory 
Max  Use:  1 


Purpose:  To  provide  a  description  of  the  included  specification  or  technical  data 
items. 


Mandatory 


_ Data  Element  Summary _ 

REF  OAT A 

PCS  tlEMEWT  NAME _ ATnfUTES 

SPI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  any  code. 

2.  If  the  data  being  transmitted  have  both  a  government  security  classification  and  a  commercial  security 
protection  requirement,  then  this  data  element  will  carry  the  government  security  classification  code  and  the 
commercial  security  protection  code  will  be  carried  in  SPI09. 

3.  If  the  data  being  transmitted  have  only  one  protection  requirement,  then  this  data  element  can  carry  either 
the  government  security  classification  code  or  the  commercial  security  protection  code. 

4.  Use  this  data  element  to  indicate  the  highest  protection  level  (government  or  commercial)  of  the  data 
being  provided.  Use  the  SPI  segment  at  the  Detail  level  to  indicate  the  protection  level  of  individual  data 
items. 


Mandatory 


Mandatory 


Not  Used 
Not  Used 
Not  Used 
Required 


SPI02  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

TN  Transaction  Reference  Number 
Code  Value  Implementation  Note: 

Use  Code  TN  for  the  unique  reference  number  of  this  transaction  set. 

SPI03  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Implementation  Note: 

The  unique  reference  number  of  this  transaction  set. 


SPI04 

790 

Entity  Title 

O 

AN 

1/132 

SPI05 

791 

Entity  Purpose 

O 

AN 

1/80 

SPI06 

792 

Entity  Status  Code 

0 

ID 

1/1 

SPI07 

353 

Transaction  Set  Purpose  Code 

Code  identifying  purpose  of  transaction  set. 

o 

ID 

2/2 

Implementation  Note: 

Use  any  appropriate  listed  code. 

00  Original 
01  Cancellation 
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Optional 


Optional 


Not  Used 
Not  Used 
Not  Used 


Code  Value  Implementation  Note: 

Use  Code  01  when  cancelling  an  841  transaction  set  which  is  providing  solicitation  technical 
documentation.  When  Code  01  is  used,  only  the  HL  segment  (HL01  and  HL03)  at  the  Detail  lev  el 
(Table  2)  is  needed. 

02  Add 
03  Delete 
04  Change 

SPI08  755  Report  Type  Code  O  ID  212 

Code  indicating  the  title  or  contents  of  a  document,  report  or  supporting  item 

SD  Support  Data  for  a  Request  for  Quote 

Code  Value  Implementation  Note: 

Use  Code  SD  to  indicate  this  transaction  set  is  providing  lechmcal  data  in  support  of  a  request  for 
quotation. 

SPI09  786  Security  Level  Code  O  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  this  data  element  ONLY  when  SPI01  is  Code  90,  92,  93,94,  or  99  and  the  data  item  being  provided 
also  has  a  commercial  security  protection  requirement. 

2.  Use  this  data  element  to  indicate  the  highest  level  of  commercial  security  protection  assigned  to  the  data 
being  provided.  Use  the  SPI  segment  at  the  Detail  level  to  indicate  the  commercial  security  protection  of 
individual  data  items. 

00  Company  Non-Classified 
01  Company  Internal  Use  Only 
02  Company  Confidential 

03  Company  Confidential,  Restricted  (Need  to  Know) 

04  Company  Registered  (Signature  Required) 

05  Personal 

09  Company  Defined  (Trading  Partner  Level) 


SPI10 

559 

Agency  Qualifier  Code 

O 

ID 

212 

SPI11 

916 

Code  List  Reference 

O 

AN 

1/6 

SPI12 

554 

Assigned  Number 

O 

NO 

1/6 
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Optional 


Segment:  NTE  Note/Special  Instruction 
Level:  Header 
Loop:  SPI 
Usage:  Optional 
Max  Use:  >1 


Purpose:  To  transmit  information  in  a  tree-form  format,  if  necessary,  tor  comment 
or  special  instruction 

Comment:  The  NTE  segment  permits  free-form  information/data  which,  under  ANSI 
XI 2  standard  implementations,  is  not  machine  processable.  The  use  of 
the  “NTE”  segment  should  therefore  be  avoided,  it  at  all  possible,  in  an 
automated  environment. 


Implementation  Note: 

Use  this  segment  to  provide  information  pertinent  to  the  entire  transaction  set.  To  provide 
information  relative  to  a  specific  data  item,  use  the  MSG  segment  in  Table  2. 


Optional 


Mandatory 


_ _ Data  Element  Summary _ 

REF.  DATA 

PIS.  ELEMENT  NAME _ ATTRMUTSS 

NTE01  363  Note  Reference  Code  O  ID  3/3 

Code  identifying  the  functional  area  or  purpose  for  which  the  note  applies. 

GEN  Entire  Transaction  Set 
Code  Value  Implementation  Note: 

Use  code  GEN  for  any  notes  that  relate  to  the  entire  transaction  set. 

NTE02  3  Free  Form  Message  M  AN  1/60 

Free-form  text. 
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Required 


Mandatory 


Conditional 


Not  Used 


Segment:  REF  Reference  Numbers 
Level:  Header 

Loop:  SPI/REF  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  specify  identifying  numbers. 

Syntax:  R0203  —  At  least  one  of  REF02  or  REF03  is  required. 

Implementation  Notes: 

1.  At  least  one  REF  segment  is  required  using  Code  KS. 

2.  Additional  repititions  of  the  REF  segment  may  be  used  to  provide  other  applicable  reference 
numbers. 

_ Data  Element  Summary _ 

REF  DATA 

DES.  ELEMENT  NAME _ ATTRIBUTES 

REF01  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

C4  Change  Number 
Code  Value  Implementation  Note: 

Use  Code  C4  for  the  contract  modification  number  to  which  the  data  being  provided  in  this 
transaction  set  pertain. 

CT  Contract  Number 
Code  Value  Implementation  Note: 

Use  Code  CT  to  specify  the  contract  number  to  which  the  data  being  provided  in  this  transaction 
set  pertain. 

KS  Solicitation 

Code  Value  Implementation  Note: 

Use  Code  KS  to  specify  the  solicitation  number  to  which  the  data  being  provided  in  this  transaction 
set  pertain. 

TN  Transaction  Reference  Number 

Code  Value  Implementation  Note: 

Use  Code  TN  for  the  unique  reference  number  of  this  transaction  set. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  ZZ  for  the  unique  reference  number  of  the  transaction  set  to  which  the  data  in  this 
transaction  set  pertain. 

REF02  127  Reference  Number  C  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

REF03  352  Description  C  AN  1/80 
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DEPARTMENT  OF  DEFENSE 

ORAFT  IMPLEMENTATION  CONVENTION 


841  •  SOLICITATION  TECHNICAL  DOCUMENTATION 
ANSI  ASCY12  VERSION/RELEASE  003030DOD_  _ DTM  •  DATE/TIME  REFERENCE 


Optional 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Syntax: 


DTM  Date/Time  Reference 
Header 
SPI/REF 
Optional 
>1 

To  specify  pertinent  dates  and  times 

R0203  —  At  least  one  of  DTM02  or  DTM03  is  required. 


Mandatory 


Conditional 


Not  Usad 
Not  Used 
Not  Used 


_ Data  Element  Summary _ 

REP.  DATA 

PIS, _ ELEMENT  NAME _ _ _ ATTRIBUTES 

DTM01  374  Date/Time  Qualifier  M  ID  3/3 

Code  specifying  type  of  date  or  time,  or  both  date  and  time. 

092  Contract  Effective 

Code  Value  Implementation  Note: 

When  REFOl  is  Code  CT,  use  Code  092  to  indicate  the  date  of  the  contract  specified  in  REF 02. 

097  Transaction  Creation 
Code  Value  Implementation  Note: 

When  REFOl  is  Code  TN,  use  Code  097  to  indicate  the  creation  dale  of  this  transaction  set. 

152  Effective  Date  of  Change 
Code  Value  Implementation  Note: 

When  REFOl  is  Code  C4,  use  Code  152  to  indicate  the  effective  date  of  the  modification  specified 
in  REF 02. 

368  Submittal 

Code  Value  Implementation  Note: 

When  REFOl  is  Code  7Z,  use  Code  368  to  indicate  the  date  of  the  referenced  transaction  set 
specified  in  REF 02. 


993  Request  for  Quotation 
Code  Value  Implementation  Note: 

When  REFOl  is  Code  KS,  use  Code  993  to  indicate  the  date  of  the  solicitation  specified  in  REF02. 


DTM02 

373 

Date 

Date  (YYMMDD). 

C 

DT 

6/6 

DTM03 

337 

Time 

C 

TM 

4/6 

DTM04 

623 

Time  Code 

O 

ID 

2/2 

DTM05 

624 

Century 

O 

NO 

2/2 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841  •  SOLICITATION  TECHNICAL  DOCUMENTATION 
N1  •  NAME _ 

Segment:  N1  Name 
Level:  Header 


ANSI  ASC  X12  VERSION/RELEASE  003030DQD 


Optional 


Loop:  SPI/N1  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 


Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 

Syntax:  1.  R0203  —  At  least  one  of  N1 02  or  N1 03  is  required. 

2.  P0304  —  If  either  N1 03  or  N104  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  “ID 
Code"  (N104)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  processing  party. 


Implementation  Note: 

Whenever  possible,  identification  and  address  information  should  be  provided  using  N101 ,  N103 , 
and  N104.  Use  NI02  and  segments  N2  through  N4  when  this  information  cannot  be  provided  by 
use  of  a  CAGE  code  or  a  DoDAAC. 


Mandatory 


Conditional 


Conditional 


Conditional 


_ Data  Element  Summary _ 

RIF.  DATA 

PCS. _ CLEMENT  NAME _ _ _ ATTWUTCS 

N101  98  Entity  Identifier  Code  M  ID  2/2 

Code  identifying  an  organizational  entity,  a  physical  location,  or  an  individual 

BY  Buying  Party  (Purchaser) 

DG  Design  Engineering 
Code  Value  Implementation  Note: 

Use  Code  DG  to  identify  a  configuration  manager. 

SE  Selling  Party 


N102 

93 

Name 

Free-form  name. 

C 

AN 

1/35 

N103 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

Code  designating  the  system/method  of  code  structure  used  for  identification 
Code  (67). 


10  Department  of  Defense  Activity  Address  Code  (DODAAC) 

33  Commercial  and  Government  Entity  (CAGE) 

N104  67  Identification  Code  C  AN  2/17 

Code  identifying  a  party  or  other  code. 
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DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


841  •  SOLICITATION  TECHNICAL  DOCUMENTATION 
ANSI  ASC  X12  VERSION/RELEASE  003030DQD_ _ N2  •  ADDITIONAL  NAME  INFORMATION 

Segment:  N2  Additional  Name  Information 
Level:  Header 


Optional 


Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  2 

Purpose:  To  specify  additional  names  or  those  longer  than  35  characters  in  length 
Implementation  Note: 

This  segment  is  not  necessary  when  the  entity  cited  in  NJ01  is  described  by  use  of  a  CAGE  code  or 
a  DoDAAC. 


Mandatory 


Optional 


Data  Element  Summary 


mam 

DATA 

ELEMENT 

NAME 

ATTHMUTES 

N201 

93 

Name 

M 

AN  1/35 

Free-form  name. 

N202 

93 

Name 

O 

AN  1/35 

Free-form  name. 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841  •  SOLICITATION  TECHNICAL  DOCUMENTATION 
N3  •  ADDRESS  INFORMATION 


N3  •  ADDRESS  INFORMATION  ANSI  ASC  X12  VERSION/RELEASE  00303000D_ 


Segment:  N3  Address  Information 
Level:  Header 
Loop:  SPI/N1 

Optional  Usage:  Optional 

Max  Use:  2 

Purpose:  To  specify  the  location  of  the  named  party 
Implementation  Note: 

This  segment  is  not  necessary  when  the  entity  cited  in  NI01  is  described  by  use  of  a  CAGE  code  or 
a  DoDAAC. 


Data  Element  Summa 


Mandatory 

Optional 


REF. 

DES. 

DATA 

ELEMENT 

NAME 

N301 

166 

Address  Information 

Address  information 

N302 

166 

Address  Information 

Address  information 

ATTimi/TtS 


M  AN  1/35 

O  AN  1/35 
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DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


841  •  SOLICITATION  TECHNICAL  DOCUMENTATION 
N4  •  GEOGRAPHIC  LOCATION 


ANSI  ASC  X12  VERSION/RELEASE  003030000_  N4  •  GEOGRAPHIC  LOCATK 


Segment:  N4  Geographic  Location 
Level:  Header 
Loop:  SPI/N1 
Optional  Usage:  Optional 

Max  Use:  1 

Purpose:  To  specify  the  geographic  place  of  the  named  party 

Syntax:  1.  R0105  —  At  least  one  of  N401  or  N405  is  required. 

2.  P0506  —  If  either  N405  or  N406  is  present,  then  the  other  is  required 

Comments:  1.  A  combination  of  either  N401  through  N404  (or  N405  and  N406)  may 
be  adequate  to  specify  a  location. 

2.  N402  is  required  only  if  city  name  (N401 )  is  in  the  USA  or  Canada. 
Implementation  Note: 

This  segment  is  not  necessary  when  the  entity  cited  in  N101  is  described  by  use  of  a  CAGE  code  or 
a  DoDAAC. 


Data  Element  Summa 


Conditional 

Optional 

Optional 

Optional 

Conditional 

Conditional 


EX 

OATA 

ELEMENT 

NAME 

Arnuftt/TES 

N401 

19 

City  Name 

Free-form  text  for  city  name. 

C 

AN  2/30 

N402 

156 

State  or  Province  Code  O  ID  2/2 

Code  (Standard  State/Province)  as  defined  by  appropriate  government  agency. 

N403 

116 

Postal  Code  O  ID  3/9 

Code  defining  international  postal  zone  code  excluding  punctuation  and  blanks 
(zip  code  for  United  States). 

N404 

26 

Country  Code 

Code  identifying  the  country. 

O 

ID  2/3 

N405 

309 

Location  Qualifier 

Code  identifying  type  of  location. 

C 

ID  1/2 

N406 

310 

Location  Identifier 

C 

AN  1/25 

Code  which  identifies  a  specific  location. 
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841  *  SOLICITATION  TECHNICAL  DOCUMENTATION 
PER  •  ADMINISTRATIVE  COMMUNICATIONS  CONTACT 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  A  SC  X12  VERSION/RELEASE  003030DOD 


Optional 


Mandatory 


Optional 


Conditional 


Conditional 


Conditional 


Conditional 


Segment:  PER  Administrative  Communications  Contact 
Level:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  identify  a  person  or  office  to  whom  administrative  communications 
should  be  directed 

Syntax:  1.  P0304  —  If  either  PER03  or  PER04  is  present,  then  the  other  is 
required. 

2.  P0506  —  If  either  PER05  or  PER06  is  present,  then  the  other  is 
required. 

Data  Element  Summa 


PER01  366  Contact  Function  Code  M  ID  2/2 

Code  identifying  the  major  duty  or  responsibility  of  the  person  or  group  named. 

1C  Information  Contact 
Code  Value  Implementation  Note: 

Use  Code  fC  for  the  information  point  of  contact  within  the  originator's  organization. 


PER02  93  Name 

Free-form  name. 

Implementation  Note: 

Use  to  provide  the  name  of  the  information  point  of  contact. 

PER03  365  Communication  Number  Qualifier 

Code  identifying  the  type  of  communication  number. 

Implementation  Note: 

Use  any  appropriate  listed  code,  although  Code  EM  is  preferred. 

EM  Electronic  Mail 
FX  Facsimile 
TE  Telephone 
TM  Telemail 


O  AN  1/35 


PER04  364  Communication  Number  C  AN  1/25 

Complete  communications  number  including  country  or  area  code  when 
applicable. 

PER05  365  Communication  Number  Qualifier  C  ID  2/2 

Code  identifying  the  type  of  communication  number. 

PER06  364  Communication  Number  C  AN  1/25 

Complete  communications  number  including  country  or  area  code  when 
applicable. 


15 


DC24  •  JULY  9  1993 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003030DOD 


841  •  SOLICITATION  TECHNICAL  DOCUMENTATION 
HL  •  HIERARCHICAL  LEVEL 


Mandatory 


Segment:  HL  Hierarchical  Level 
Level:  Detail 


Loop:  HL  Repeat:  >1 
Usage:  Mandatory 
Max  Use:  1 


Purpose:  To  identify  dependencies  among  and  the  content  of  hierarchically  related 
groups  of  data  segments. 

Comments:  1.  The  HL  Segment  is  used  to  identify  levels  of  detail  information  using  a 
Hierarchical  Structure,  such  as  relating  line  item  data  to  shipment  data, 
and  packaging  data  to  line  item  data. 

2.  The  HL  segment  defines  a  top-down/left-right  ordered  structure. 

3.  HL01  shall  contain  a  unique  alphanumeric  number  for  each 
occurrence  of  the  HL  segment  in  the  transaction  set.  For  example  HL01 
could  be  used  to  indicate  the  number  of  occurrences  of  the  HL  segment, 
in  which  case  the  value  of  HL01  would  be  "1"  for  the  initial  HL  segment, 
and  would  be  incremented  by  one  in  each  subsequent  HL  segment 
within  the  transaction. 


4.  HL02  identifies  the  Hierarchical  ID  Number  of  the  HL  segment  to 
which  the  current  HL  segment  is  subordinate. 

5.  HL03  indicates  the  context  of  the  series  of  segments  following  the 
current  HL  segment  up  to  the  next  occurrence  of  an  HL  segment  in  the 
transaction.  For  example,  HL03  is  used  to  indicate  that  subsequent 
segments  in  the  HL  loop  form  a  logical  grouping  of  data  referring  to 
shipment,  order  or  item  level  information. 

6.  HL04  indicates  whether  or  not  there  are  subordinate  (or  child)  HL 
segments  related  to  the  current  HL  segment. 

Implementation  Notes: 

1.  The  HL  loop  can  be  used  to  transmit  a  single  item  of  technical  information  or  multiple  items  that 
may  or  may  not  have  a  hierarchical  relationship. 

2.  When  providing  a  single  item  of  technical  information,  only  one  iteration  of  the  HL  loop  is 
necessary. 

3.  When  transmitting  multiple  items  that  may  or  may  not  have  a  hierarchical  relationship,  repeat 
the  HL  loop  as  many  times  as  required  to  specify  all  levels  and  use  as  many  iterations  of  the 
HUS  PI  loop  as  necessary. 

4.  When  SPI07  is  Code  01,  the  only  entries  in  the  Detail  level  (Table  2)  are  in  HU) l  and  HL03. 


Mandatory 


_ Data  Element  Summary _ 

KEF.  OAT  A 

DES  ELEMENT  NAME _ ATTMUUTES 

HL01  628  Hierarchical  ID  Number  M  AN  1/12 

A  unique  number  assigned  by  the  sender  to  identify  a  particular  data  segment  in 
a  hierarchical  structure. 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841  •  SOLICITATION  TECHNICAL  DOCUMENTATION 
HL  •  HIERARCHICAL  LEVEL 


ANSI  ASC  X12  VERSION/RELEASE  003030DOD 


Optional 


Mandatory 


Implementation  Note: 

This  unique  and  progressive  number  is  assigned  by  the  originator  of  the  transaction  set  starling  with  the 
number  I . 

HL02  734  Hierarchical  Parent  ID  Number  O  AN  1/12 

Identification  number  of  the  next  higher  hierarchical  data  segment  that  the  data 
segment  being  described  is  subordinate  to. 

Implementation  Note: 

This  data  element  is  used  only  when  providing  multiple  items  of  technical  information  that  have  a 
hierarchical  relationship. 

HL03  735  Hierarchical  Level  Code  M  ID  1/2 

Code  defining  the  characteristic  of  a  level  in  a  hierarchical  structure. 

Implementation  Note: 

Use  any  appropriate  listed  code  to  indicate  the  hierarchical  relationship  of  the  data  provided 

A  Assembly 
F  Component 
I  Item 

Code  Value  Implementation  Note: 

Use  Code  I  as  the  default  code  when  no  other  code  is  applicable. 

SY  System 
U  Subassembly 
ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  ZZ  only  when  SP/07  is  Code  01  .This  is  required  to  comply  with  the  mandatory  nature  of 
this  data  element. 


Optional 


HL04  736  Hierarchical  Child  Code  O  ID  1/1 

Code  indicating  whether  if  there  are  hierarchical  child  data  segments  subordinate 
to  the  level  being  described. 

Implementation  Note: 

When  providing  single  or  multiple  specifications/ technical  information  that  have  no  hierarchical  relationship, 
no  entry  is  required. 

0  No  Subordinate  HL  Segment  in  This  Hierarchical  Structure. 

Code  Value  Implementation  Note: 

Use  Code  0  to  indicate  the  lowest  level  in  the  hierarchical  relationship. 

1  Additional  Subordinate  HL  Data  Segment  in  This  Hierarchical  Structure. 

Code  Value  Implementation  Note: 

Use  Code  l  to  indicate  there  are  lower  level  items  in  this  hierarchical  relationship. 
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DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENT  AT  ION  CONVENTION 


841  •  SOLICITATION  TECHNICAL  DOCUMENTATION 
ANSI  ASC  X12  VERSION/RELEASE  003030PQD_  _  _  SPI  •  SPECIFICATION  IDENTIFIER 


Optional 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 


SPi  Specification  Identifier 
Detail 

HUS  PI  Repeat:  >1 
Optional 
1 

To  provide  a  description  of  the  included  specification  or  technical  data 
items. 


Mandatory 


Mandatory 


Mandatory 


Optional 


_ Data  Element  Summary _ 

MF  DATA 

MS. _ ILSMPff  NASH  _ ATTWISUTSS 

SPI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  ot  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  any  code. 

2.  If  the  data  item  being  transmitted  has  both  a  government  security  classification  and  a  commercial  security 
protection  requirement,  then  this  data  element  will  carry  the  government  security  classification  code  and  the 
commercial  security  protection  code  will  be  carried  in  SPI09. 

3.  If  the  data  item  being  transmitted  has  only  one  protection  requirement,  then  this  data  element  can  carry 
either  the  government  security  classification  code  or  the  commercial  security  protection  code. 

SPI02  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

Implementation  Note: 

Any  code  can  be  used  but  typically  used  codes  include: 

DD  Document  Identification  Code 

Code  Value  Implementation  Note: 

Use  Code  DD  for  the  reference  number  of  an  Engineering  Data  List. 

DG  Drawing  Number 

QC  Product  Specification  Document  Number 

51  Engineering  Specification  Number 

52  Military  Specification  Number  (MILSPEC) 

53  Specification  Number 

TP  Test  Specification  Number 
W9  Special  Packaging  Instruction  Number 
ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  ZZ  for  another  type  of  reference  number  and  identify  that  number  in  SP104. 

SPI03  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

SPI04  790  Entity  Title  O  AN  1/132 

Title  of  the  data  entity. 


DC24  •  JULY  9  1993 


18 


DEPARTMENT  Of  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841  •  SOLICITATION  TECHNICAL  DOCUMENTATION 

SPI  •  SPECIFICATION  IDENTIFIER  ANSI  ASC  X12  VERSION/RELEASE  003030DOD 


Not  Used 
Optional 


Not  Used 
Not  Used 
Optional 


Not  Used 
Not  Used 
Not  Used 


Implementation  Note: 

When  SPI02  is  Code  72.  identify  the  reference  number  cued  in  SPI03. 


SPI05 

791 

Entity  Purpose 

O  AN  1/80 

SPI06 

792 

Entity  Status  Code 

O  ID  1/1 

Code  indicating  the  current  status  of  the  data  item  specified  by  the  electronic 
data  item. 


Implementation  Note: 

Use  any  code. 

Z  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  Zfor  another  entity  status  condition  and  explain  in  the  MSG  segment. 


SPI07 

353 

Transaction  Set  Purpose  Code 

O  ID 

2/2 

SPI08 

755 

Report  Type  Code 

O  ID 

2/2 

SPI09 

786 

Security  Level  Code  O  ID 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

2/2 

Implementation  Note: 

Use  this  data  elemnent  ONLY  when  SPIOI  is  Code  90,  92,  93,  94,  or  99  and  the  data  item  being  provided  also 
has  a  commercial  security  protection  requirement . 


00  Company  Non-Classified 
01  Company  Internal  Use  Only 
02  Company  Confidential 

03  Company  Confidential,  Restricted  (Need  to  Know) 
04  Company  Registered  (Signature  Required) 

05  Personal 

09  Company  Defined  (T rading  Partner  Level) 


SPI10 

559 

Agency  Qualifier  Code 

O 

ID 

2/2 

SPI11 

916 

Code  List  Reference 

O 

AN 

1/6 

SPI12 

554 

Assigned  Number 

O 

NO 

1/6 
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DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  A  SC  X12  VERSION/RELEASE  003030DOD 


841  •  SOLICITATION  TECHNICAL  DOCUMENTATION 
RDT  •  REVISION  DATE-TIME 


Optional 


Optional 


Conditional 


Optional 


Conditional 


Not  Used 
Not  Used 


Segment:  RDT  Revision  Date/Time 
Level:  Detail 
Loop:  HL/SPI 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  specify  the  revision  level  of  the  electronic  data  item. 

Syntax:  1.  C0102  —  If  RDT01  is  present,  then  RDT02  is  required. 

2.  L030405  —  If  RDT03  is  present,  then  at  least  one  of  RDT04  or 
RDT05  are  required. 

3.  C0605  —  If  RDT06  is  present,  then  RDT05  is  required. 
Implementation  Note: 

Use  this  segment  to  specify  the  change,  revision  or  version  of  the  specification/technical 
information  being  provided. 

_ Data  Element  Summary _ 


nr 

DCS. 


DATA 

ILEMEMT  NAME 


RDT01  795  Revision  Level  Code  O  ID 

Code  indicating  the  revision  or  engineering  change  level  of  the  data  items 
referred  to  by  the  specification  number. 

A  Change  Lsvel 
E  Revision  Level 
H  Version  Level 

RDT02  796  Revision  Value  C  AN 

Revision  or  engineering  change  level  of  the  data  items  referred  to  by  the 
specification  number. 

Implementation  Notes: 

1.  When  RDT01  is  Code  A  or  Code  E,  use  to  enter  the  change  or  revision  number! letter. 

2.  When  RDTOl  is  Code  H,  specify  the  version  being  transmitted,  e  g.,  "As-Built"  or  "As-Shipped". 

RDT03  374  Date/Time  Qualifier  O  ID 

Code  specifying  type  of  date  or  time,  or  both  date  and  time. 

007  Effective 

Code  Value  Implementation  Note: 

Use  Code  007  to  specify  the  change,  revision,  or  version  date. 

RDT04  373  Date  C  DT 

Date  (YYMMDD). 

Implementation  Note: 

Enter  the  date  of  the  change,  revision,  or  version  being  transmitted  in  this  transaction  set. 


1/1 


1/30 


3/3 


6/6 


RDT05 

RDT06 


337 

623 


Time 

Time  Code 


C 

O 


TM 

ID 


4/6 

2/2 
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Segment:  LIN  item  Identification 
Level:  Detail 
Loop:  HUSPI 

Optional  Usage:  Optional 

Max  Use:  1 

Purpose:  To  specify  basic  item  identification  data. 

Syntax:  1.  C0405  —  If  LIN04  is  present,  then  LIN05  is  required. 

2.  C0607  —  If  LIN06  is  present,  then  LIN07  is  required. 

3.  C0809  —  If  LIN08  is  present,  then  LIN09  is  required. 

4.  Cl  01 1  —  If  LIN10  is  present,  then  LIN1 1  is  required. 

5.  C1213  —  If  LIN12  is  present,  then  LIN13  is  required. 

6.  C1415  —  If  LIN14  is  present,  then  LIN15  is  required. 

7.  Cl  Pi  7  —  If  LIN16  is  present,  then  LIN17  is  required. 

8.  Cl  81 9  —  If  LIN18  is  present,  then  LIN19  is  required. 

9.  C2021  —  If  LIN20  is  present,  then  LIN21  is  required. 

10.  C2223  —  If  LIN22  is  present,  then  LIN23  is  required. 

11.  C2425  —  If  LIN24  is  present,  then  LIN25  is  required. 

12.  C2627  —  If  LIN26  is  present,  then  LIN27  is  required. 

13.  C2829  —  If  LIN28  is  present,  then  LIN29  is  required. 

14.  C3031  —  If  LIN30  is  present,  then  LIN31  is  required. 

Semantic:  LIN01  is  the  line  item  identification 

Comments:  1.  See  the  Data  Dictionary  for  a  complete  list  of  ID  s. 

2.  LIN02  through  LIN31  provide  for  fifteen  (15)  different  product/service 
ID's  for  each  item.  For  Example:  Case,  Color,  Drawing  No.,  UPC  No., 
ISBN  No.,  Model  No.,  SKU. 

Implementation  Notes: 

1.  Use  this  segment  to  transmit  information  relative  to  the  data  item  identified  in  SPI03,  e.g., 
national  stock  number  (NSN),  part  number,  item  description,  etc.. 

2.  LIN02  through  LIN3]  are  used  in  pairs  (i.e.,  UN02  and  LIN03)  as  required  to  carry  additional 
information  about  the  specific  data  item  identified  in  SPI03. 

_ Data  Element  Summary _ 

AEF  OAT* 

DES-  ELEMENT  NAME _ ATTWOUTES 

Not  Used  LIN01  350  Assigned  Identification  O  AN  1/11 

Mandatory  LIN02  235  Product/Service  ID  Qualifier  M  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

F7  End-Item  Description 
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Mandatory 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 


Code  Value  Implementation  Note: 

Use  Code  F'\,^r  the  application  reference  from  an  Engineering  Data  List. 

FS  National  Stock  Number 
Code  Value  Implementation  Note: 

Use  Code  FS  for  the  National  Stock  Number. 

IN  Buyer's  Item  Number 

Code  Value  Implementation  Note: 

Use  Code  IN  for  the  CLIN  or  SUBCLIN . 

MG  Manufacturer's  Part  Number 

Code  Value  Implementation  Note: 

Use  Code  MG  for  a  manufacturer’s  part  number. 

PD  Part  Number  Description 

Code  Value  Implementation  Note: 

Use  Code  PD  for  the  noun  description  from  an  Engineering  Data  List. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  ZZ  for  the  Data  Tech  organization. 


LIN03 

LIN04 

LIN05 

LIN06 

LIN07 

LIN08 

LIN09 

LIN1G 

LIN11 

LIN12 


234  Product/Service  ID 

Identifying  number  for  a  product  or  service. 


M  AN  1/30 


235  Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 


ID 


2/2 


234  Product/Service  ID 

Identifying  number  for  a  product  or  service. 


C  AN  1/30 


235  Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descnptive  number  used  in 
Product/Service  ID  (234). 


ID 


2/2 


234  Product/Service  ID 

Identifying  number  for  a  product  or  service. 


C  AN  1/30 


235  Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 


ID 


2/2 


234  Product/Service  ID 

Identifying  number  for  a  product  or  service. 


C  AN  1/30 


235  Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 


ID 


2/2 


234  Product/Service  ID 

Identifying  number  for  a  product  or  service. 


C  AN  1/30 


235  Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 


ID 


LIN13  234  Product/Service  ID 


C  AN 


2/2 


1/30 
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Identifying  number  for  a  product  or  service. 

Optional 

LIN14 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN15 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN16 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN17 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN18 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN19 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN20 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN21 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN22 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN23 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN24 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN25 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN26 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN27 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN28 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN29 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 
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Optional 


Conditional 


235  Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

234  Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 
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Optional 


Segment:  N1  Name 
Level:  Detail 
Loop:  HL/SPI 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 

Syntax:  1.  R0203  —  At  least  one  of  N102  or  N103  is  required. 

2.  P0304  —  If  either  N103  or  N104  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code"  (N104)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  processing  party. 


Mandatory 


Conditional 


Conditional 


Conditional 


_  Data  Element  Summary _ 

REF.  DATA 

PCS.  ElEMEWT  NAME _ ATTWRUTEE 

N101  98  Entity  Identifier  Code  M  ID  2/2 

Code  identifying  an  organizational  entity,  a  physical  location,  or  an  individr  - 1 

33  Inquiry  Address 
Code  Value  Implementation  Note: 

Use  Code  33  to  identify  a  Data  Tech  entity  from  an  Engineering  Data  List . 

ZE  End  Item  Manufacturer 
Code  Value  Implementation  Note: 

Use  Code  ZE  to  identify  the  manufacturer  from  an  Engineering  Data  List. 


N102 

93 

Name 

Free-form  name. 

C 

AN 

1/35 

N103 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 

10  Department  of  Defense  Activity  Address  Code  (DODAAC) 

33  Commercial  and  Government  Entity  (CAGE) 

N104  67  Identification  Code  C  AN  2/17 

Code  identifying  a  party  or  other  code. 
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Segment:  MSG  Message  Text 
Level:  Detail 


Optional 


Loop:  HUSPI 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  provide  a  free  form  format  that  would  allow  the  transmission 
information. 

Comment:  MSG02  is  not  related  to  the  specific  characteristics  of  a  printer, 
identifies  top  of  page,  advance  a  line,  etc. 

Implementation  Notes: 

1.  Use  this  segment  to  transmit  information  relative  to  a  specific  data  item. 

2.  Maximum  use  is  3 . 


of  text 
but 


Mandatory 

Not  Usad 


Data  Element  Summary 


DATA 

ELEMENT 

NAME 

ATTftWUTES 

MSG01 

933 

Free-Form  Message  Text 

Free-form  message  text. 

M 

AN 

1/264 

MSG02 

934 

Printer  Carriage  Control  Code 

O 

ID 

2/2 
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Optional 


Segment:  EFI  Electronic  Format  Identification 
Level:  Detail 

Loop:  HUEFI  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  provide  basic  information  about  the  electronic  format  of  the 
interchange  data. 

Syntax:  1.  C0504  —  If  EFI05  is  present,  then  EFI04  is  required. 

2.  C0706  —  If  EFI07  is  present,  then  EFI06  is  required. 

3.  C0908  —  If  EFI09  is  present,  then  EFI08  is  required. 

Implementation  Note: 

Maximum  use  is  I  for  each  HL. 


Mandatory 


Optional 


_ Data  Element  Summary _ 

WF  DATA 

DES  ELEMENT  NAME _ _ _ ATTfHUJTES 

EFI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  any  appropriate  code. 

2.  The  security  level  code  specified  here  relates  to  the  specific  binary  data  provided  in  the  BIN  segment. 

3.  The  security  code  provided  for  the  binary  data  being  transmitted  in  the  BIN  segment  is  the  highest 
protection  level  assigned  to  the  data.  If  the  data  have  both  a  government  security  classification  and  a 
commercial  security  protection  requirement,  the  government  security  classification  takes  precedence  and 
shall  be  provided  in  this  data  element. 

EFI02  933  Free-Form  Message  Text  O  AN  1/264 

Free-form  message  text. 

Implementation  Note: 

Use  only  if  necessary  to  transmit  a  short  remark  or  note  about  the  binary  information  being  transmitted  in 
this  transaction  set. 


Optional 


EFI03  797  Security  Technique  Code  O  ID  2/2 

Code  indicating  that  this  element  will  be  used  to  tell  an  EDI  translator  program 
which  security  tehnique  to  use. 

Implementation  Note: 

Use  any  code. 


Conditional 


EFI04  799  Version  Identifier  C  AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm. 

Implementation  Note: 

Use  to  specify  the  version,  e.g.,  2.0, 3.2,  etc.,  of  the  program  being  used  to  transmit  the  data  in  the  following 
BIN  segment.  This  data  element  pertains  to  the  program  identifier  specified  in  EFI05. 


Optional 


EFI05  802  Program  Identifier 


O  AN  1/30 
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Identifies  the  name  of  the  software  program  from  which  the  technical  data 
originates. 

Implementation  Note: 

Use  to  specify  the  application  software  program  used  to  create  the  data  being  transmitted  in  the  following 

BIN  segement,  e  g.,  TruckCad,  ClassSCad,  etc. 

Conditional 

EFI06  799  Version  Identifier  C  AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm. 

Implementation  Note: 

Use  to  identify  the  specific  version  of  the  interchange  standard  used  to  transmit  the  data  in  the  following  BIN 
segment.  This  data  element  pertains  to  the  interchange  format  specified  in  EFI07. 

Optional 

EFI07  801  Interchange  Format  O  AN  1/30 

Industry  or  proprietary  standard  used  to  identify  the  format  of  the  data. 

Implementation  Note: 

Use  to  enter  the  specification  number  or  description  of  the  version  noted  in  EFIOb.  Examples  include  MIL-D- 
28000 for  IGES  and  MIL-R-28002  for  Raster. 

Conditional 

EFI08  799  Version  Identifier  C  AN  1/30 

Revision  level  of  a  particular  format,  program,  technique  or  algorithm. 

Implementation  Note: 

Use  to  identify  the  version  of  the  program  used  to  compress  the  data  transmitted  in  the  following  BIN 
segment.  This  data  element  pertains  to  the  compression  technique  program  specified  in  EFI09. 

Optional 

EFI09  800  Compression  Technique  O  AN  1/30 

Identifies  the  digital  data  compression  means  and  the  type. 

Implementation  Note: 

Use  to  identify  the  compression  method,  if  any,  applied  to  the  data  transmitted  in  the  following  BIN  segment. 
Examples  include  TR,  Moyer,  Fish,  etc. 

Optional 

EFI10  789  Drawing  Sheet  Size  Code  O  ID  2/2 

Code  indicating  the  drawing  size  and  orientation  of  a  technical  drawing  as 
specified  and  described  in  the  current  version  of  standards  ANSI  Y14.1  and  ISO 
5457  (E).  See  the  listed  ANSI  and  ISO  standards  for  the  maximum  lengths  for 
rolled  sheets.* 

Implementation  Notes: 

1.  Use  to  specify  the  drawing  sheet  size  if  the  data  transmitted  in  the  BIN  segment  are  to  be  presented  in  a 
hard  copy  as  well  as  stored  in  the  receiver's  system. 

2.  Use  any  code. 

Optional 

EFI11  803  File  Name  O  AN  1/64 

Name  assigned  or  declared  for  a  file  or  used  by  a  program  to  identify  a  file.  Exact 
format  of  the  name  depends  on  the  computer  operating  system  being  used. 

Name  also  may  be  known  as  the  file’s  "data  set  name". 

Implementation  Note: 

Use  to  enter  the  file  name  of  the  data  to  be  transmitted. 

Not  Used 

Not  Used 

Not  Used 

EFI12  804  Block  Type  O  AN  1/4 

EFI13  787  Record  Length  O  N  1/15 

EFI14  788  Block  Length  O  N  1/5 
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Optional 


Segment:  BIN  Binary  Data 
Level:  Detail 
Loop:  HL/EFI 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  transfer  binary  data  in  a  single  data  segment  and  to  allow 

identification  of  the  end  of  the  data  segment  through  a  count.  There  is  no 
identification  of  the  internal  structure  of  the  binary  data  in  this  segment. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

RCP.  DATA 

DES _ ELEMENT  NAME _ ATTRIBUTES 


BIN01  784  Length  of  Binary  Data 

The  length  in  integral  octets  of  the  binary  data. 

M 

NO 

1/15 

BIN02  785  Binary  Data 

M 

B 

1/10 

A  string  of  octets  which  can  assume  any  binary  pattern  from  hexadecimal  00  to 
FF. 
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Segment:  SE  Transaction  Set  Trailer 
Level:  Summary 


Mandatory 


Loop: 
Usage: 
Max  Use: 
Purpose: 

Comment: 


Mandatory 

1 

To  indicate  the  end  of  the  transaction  set  and  provide  the  count  of  the 
transmitted  segments  (including  the  beginning  (ST)  and  ending  (SE) 
segments). 

SE  is  the  last  segment  of  each  transaction  set. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

AiF.  DAT* 

PIS. _ tLPWWT  MAAIt _ ATTWUTtS 

SEOi  96  Number  of  Included  Segments  M  NO  1/10 

Total  number  of  segments  included  in  a  transaction  set  including  ST  and  SE 
segments. 

SE02  329  Transaction  Set  Contool  Number  M  AN  4/9 

Identifying  control  number  that  must  be  unique  within  the  transaction  set 
functional  group  assigned  by  the  originator  for  a  transaction  set 

Implementation  Note: 

Enter  the  same  number  as  carried  in  ST02. 
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ASC  XI 2  WORK  REQUEST  FORM 
SUBMITTER  INSTRUCTIONS 

NOTE:  ALL  REQUESTS  MUST  BE  TYPED  OR  PRINTED  LEGIBLY  IN  BLACK  INK- 
INCOMPLETE  OR  ILLEGIBLE  WORK  REQUESTS  WILL  BE  RETURNED  TO  THE 
SUBMITTER. 

Submit  completed  forms  to:  Technical  Department.  ASC  X12  Secretariat  Data  Interchange  Standards  Association, 
Inc..  1800  Diagonal  Road.  Suite  355.  Alexandria.  VA  22314-2852  or  FAX  (703)  548-5738.  Submitters  are  notified  of 
the  status  of  the  work  request  after  it  has  been  reviewed  by  X12J  Technical  Assessment  Subcommittee. 

1.  TO  USE  THIS  FORM  TO  REQUEST  A  CHANGE  TO  AN  EXISTING  STANDARO(S).  use  ONE  Work  Request 
(WR)  Form  to  list  all  changes  needed  to  meet  one  BUSINESS  REASON.  Otherwise  use  multiple  forms.  If  more 
space  is  necessary,  numbered  attachments  may  be  used  for  continuation. 

2.  TO  USE  THIS  FORM  FOR  SUPPORTING  OATA  MAINTENANCE  FOR  A  NEW  DRAFT  STANDARD,  list  afl 
information  on  ONE  form;  use  attachments  as  necessary.  List  first  afl  new  segments,  then  afl  new  data 
elements/codes/code  sources.  Then  list  revisions  to  existing  segments  and  data  elements/codes/code  sources; 
provide  a  business  case  for  revisions  to  existing  standards.  Then  list  any  others  changes  needed  (e.g.,  X12.5, 

Xi 2.6).  including  justification. 

3.  TO  USE  THIS  FORM  TO  REQUEST  A  PROPOSED  NEW  X12  STANDARDS  PROJECT,  provide  the  business 
need  and  justification  for  the  new  project  in  Part  0.  The  WR  wU  be  referred  to  an  X12  subcommittee  tor  analysis. 

ADDITIONAL  INFORMATION  FOR  COMPLETING  THIS  FORM: 

PART  A:  SUBMITTER  INFORMATION:  The  WR  may  represent  the  position  of  an  individual,  industry  group,  work 
group.  Xi  2  subgroup,  etc.  If  the  WR  represents  the  position  of  an  XI 2  subcommittee  related  work  group,  the 
subcommittee  chair  must  initial  the  WR. 

PART  B:  REFERENCE  USED:  Indicate  the  version/release  or  edition  of  the  standard  you  are  using  as  a  reference. 

PART  C:  RAMIFICATIONS:  List  affected  transaction  sets,  segments  and  data  elements,  or  other  standards.  For  a 
control  standard,  name  the  affected  page  and  section  number. 

PART  D:  BUSINESS  CASE/REASON  FOR  CHANGE:  Provide  a  complete  scenario  that  describes  the  businees 
function/operation  that  wfll  be  satisfied  by  a  change  to  the  standard.  Be  specific,  because  this  Information  wB 
appear  in  the  X12  membership  ballot  package  and  will  be  the  only  information  that  members  have  on  which  to  base 
their  vote.  X12J  Technical  Assessment  Subcommittee  requires  enough  Information  to  be  able  to  propose  an 
alternate  solution  to  the  one  provided,  If  necessary. 

PART  E:  PROPOSED  WORK:  Ust  the  specific  changes  being  requested.  Give  the  names  and  associated 
identifiers  of  the  standards  segments,  data  elements  and  codes  affected  by  the  changes.  Definitions  for  new  codes 
and  for  industry-specific  terms  must  be  complete.  For  new  codes,  provide  a  proposed  code  and  a  code  definition. 
RULES:  (1)  Acronyms/abbreviations  cannot  be  added  to  the  standards-they  must  be  spefledouL  (2)  Provide  an 
expanded  code  definition  for  each  code  that  is  not  completely  seif  explanatory,  that  is,  terms  that  are  not  m  genaral 
business  use  or  that  are  Industry  specific.  (3)  Provide  code  source  references  for  afl  extemafly  published  (norvXi2) 
code  lists  cited  (use  the  Form  for  New  or  Revised  Code  Source  Reference,  page  2  of  the  form). 
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WR  Form  Pa^e  Two  DM  NUMBER 

(Secretariat  Only) 

FORM  FOR  NEW  OR  REVISED  CODE  SOURCE  REFERENCE 
FOR  XI  2.3  DATA  ELEMENT  DICTIONARY 

INSTRUCTIONS:  Complete  this  form  whenever  a  new  data  element  or  data  element  code  la  requested  to  be 
added  to  Appendix  A  of  X  72. 3  Data  Element  Dictionary,  which  references  a  code  list  published  by  an  organization 
external  to  Xi2.  Use  one  form  for  each  new  reference.  This  form  may  be  used  to  revise  current  references;  f#  out 
the  appropriate  areas  below. 

PART  1 :  REFERENCE  Circle  t  or  2  oeiow  it  2.  fill  in  mo  blank. 

(1)  NEW  REFERENCE 

(2)  REVISED  REFERENCE.  Current  reference  number/name _ 

PART  2:  REFERENCE  TITLE  R  twt  *  only  o no  aourot  tor  ooOoo  ter  me  Sate  Moment,  the  Me  ahouM  be  me  aame  ee  the  oete 
element  nemo,  e  there  ere  multiple  oodoe  retereneine  external  oode  eouraee  tor  me  eame  date  element  Me  ahouM  epproomeee  the  oode 
definition. 

REFERENCE  TITLE: 

PART  3:  DATA  ELEMENTS  USED  IN  ON*  the  data  element  reference  number  end  nemo  which  dtrecte  tie  ueer  ao  Me  oode 
aoureo.  Give  the  oode  10  (If  aaalgned)  H  thia  la  for  a  apeeifle  oode  of  the  data  Moment 

USED  IN:  DENo. _ .Coda  ID _ 

PART  4:  SOURCE  Provide  the  nemo  of  the  publication  which  contMne  the  oodoe  tofotenuod. 

PUBUSHED  IN: 

PART  S:  AVAILABLE  FROM  Give  me  puMiaher,  or  other  oontact,  from  whom  me  ueer  ean  obtain  me  document 

AVAILABLE:  Name/Attn  of  _ 

Company  _ 

Addraaa  _ 

Add  rata  _ _ 

Addrasa/ZJP  _ /ZIP  ♦  4 _ 


PART  •:  ABSTRACT  Briefly  deoenbe  the  publication,  ita  purpoea,  and  mdktete  what  oodoe  It  oontMne. 
ABSTRACT: 
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5.0  GLOSSARY 


This  chapter  contains  ASC  XI 2-  and  DoD-specific  glossaries. 

5.1  X12  GLOSSARY 

ANSI 

American  National  Standards  Institute 

ANSI  Standard 

A  document  published  by  ANSI  that  has  been  approved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
such  standards  must  have  been  developed  by  an  ANSI  committee 
and  must  be  revisited  by  that  committee  within  S  years  for  updat¬ 
ing.  See  Draft  Standard  for  Trial  Use  (DSTU). 

Area  Transaction  Set 

A  predefined  area  within  a  transaction  set  (header,  detail,  sum¬ 
mary)  containing  segments  and  their  various  attributes. 

ASC  X12 

Accredited  Standards  Committee,  X12.  It  comprises  industry 
members  who  create  electronic  data  interchange  (EDI)  standards 
for  submission  to  ANSI  for  subsequent  approval  and  dissemination. 

Authentication 

A  mechanism  that  allows  the  receiver  of  an  electronic  transmission 
to  verify  the  sender  and  the  integrity  of  the  content  of  the  trans¬ 
mission  through  the  use  of  an  electronic  “key”  or  algorithm  shared 
by  the  trading  partners.  That  algorithm  is  sometimes  referred  to 
as  an  electronic  signature. 

Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Conditional  (C) 

A  data  element  requirement  designator  that  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value  or 
presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  computer  processable. 

Control  Segment 

A  segment  that  has  the  same  structure  as  a  data  segment  but  is 
used  for  transferring  control  information  for  grouping  data  seg¬ 
ments.  Control  segments  may  be  loop  control  segments  (LS/LE), 
transaction  set  control  segments  (ST/SE),  or  functional  group  con¬ 
trol  segments  (GS/GE),  defined  in  X12.6,  or  interchange  control 
segments  (ISA/IEA/TA1)  defined  in  X12.5. 
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Data  Element 

The  basic  unit  of  information  in  the  EDI  standards  containing  a 
set  of  values  that  represent  a  singular  fact.  It  may  be  single-char¬ 
acter  codes,  literal  descriptions,  or  numeric  values. 

Data  Element  Length 

The  range,  minimum  to  maximum,  of  the  number  of  character 
positions  available  to  represent  the  value  of  a  data  element.  A 
data  element  may  be  of  variable  length  and  range  from  minimum 
to  maximum  or  it  may  be  of  fixed  length  in  which  the  minimum 
is  equal  to  the  maximum. 

Data  Element  Reference  Number 

Number  assigned  to  each  data  element  as  a  unique  identifier. 
Data  Element  Requirement  Designator 

A  code  defining  the  need  for  a  data  element  value  to  appear  in  the 
segment  if  the  segment  is  transmitted.  The  X12  codes  are  man¬ 
datory  (M),  optional  (O),  or  conditional  (C).  DoD  may  consider 
a  segment  “mandatory”  even  through  it  is  “optional”  by  X12 
standards. 

Data  Element  Separator 

A  unique  character  preceding  each  data  element  that  is  used  to 
delimit  data  elements  within  a  segment.  DoD  uses  as  the 
delimiter. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types:  numeric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

Two  levels  of  separators  and  a  terminator.  The  delimiters  are  an 
integral  part  of  the  transferred  data  stream.  They  are  specified  in 
the  interchange  header  and  may  not  be  used  in  a  data  element 
value  elsewhere  in  the  interchange.  From  highest  to  lowest  level, 
the  separators  and  terminator  are  segment  terminator  and  data 
element  separator. 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organization 
funded  by  ASC  X12  members  to  serve  as  the  Secretariat  for  XI 2. 

DSTU 

Draft  Standard  for  Trial  Use.  It  represents  a  document  approved 
for  publication  by  the  full  XI 2  committee  following  membership 
consensus  and  subsequent  resolution  of  negative  votes.  (Final 
Report  of  X12  Publications  Task  Group).  The  Draft  EDI  Standard 
for  Trial  Use  document  represents  an  ASC  X12  approved  standard 
for  use  prior  to  approval  by  ANSI.  See  ANSI  Standard. 
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EDI 

Electronic  data  interchange.  The  computer-application-to-com- 
puter-application  exchange  of  business  information  in  a  standard 
format. 

Electronic  Envelope 

Electronic  information  that  binds  together  a  set  of  transmitted 
documents  being  sent  from  one  sender  to  one  receiver. 

Element  Delimiter 

A  single-character  that  follows  the  segment  identifier  and  separates 
each  data  element  in  a  segment  except  the  last. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functional 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  Segments  (GS/GE) 

These  segments  identify  a  specific  functional  group  of  documents 
such  as  purchase  orders. 

Industry  Conventions 

Defines  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  how  to  implement  XI 2  stand¬ 
ards. 

Interchange  Control  Segments  (ISA/IEA) 

These  segments  identify  a  unique  interchange  being  sent  from  one 
sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Structure 

The  interchange  header  and  trailer  segments  that  envelop  one  or 
more  functional  groups  or  interchange-related  control  segments  and 
perform  the  following  functions:  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  information  for  the  inter¬ 
change,  and  (4)  allows  for  authorization  and  security  information. 
(X12.5) 

Loop 

A  group  of  semantically  related  segments;  these  segments  may  be 
either  bounded  or  unbounded  (X12.6).  The  N1  loop  is  an  example 
of  a  loop,  which  includes  Segments  N1  to  PER  for  name  and 
address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  that  indicates  the 
presence  of  a  specified  data  element  is  required. 
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Mapping 

The  process  of  identifying  the  standard  data  element’s  relationship 
to  application  data  elements. 

Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used  at 
the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
Optional  (O) 

A  data  element/segment  requirement  designator  that  indicates  the 
presence  of  a  specified  data  element/segment  is  at  the  option  of 
the  sending  party  and  can  be  based  on  the  mutual  agreement  of 
the  interchange  parties. 

Qualifier 

A  data  element  that  identifies  or  defines  a  related  element,  set  of 
elements,  or  a  segment  The  qualifier  contains  a  code  taken  from 
a  list  of  approved  codes. 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set  See  Max  Use. 

Security 

System  screening  that  denies  access  to  unauthorized  users  and 
protects  data  from  unauthorized  uses 

Segment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifier,  one  or 
more  data  elements  each  preceded  by  an  element  separator,  and 
a  segment  terminator. 

Segment  Directory 

Provides  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifier  for  a  segment,  consisting  of  a  combination  of 
two  or  three  upper-case  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment.  It  is  not  a 
data  element.  The  segment  identifier  in  EDIFACT  is  a  component 
data  element  —  part  of  a  composite  data  element  consisting  of  a 
segment  identifier  and  an  explicit  looping  designator. 
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Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment,  e.g.,  N/L. 

Syntax 

The  grammar  or  rules  that  define  the  structure  of  the  EDI  standards 
(i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules  are  published 
in  ANSI  X12.6. 

Transaction  Set 

A  document  that  unambiguously  defines,  in  the  standard  syntax, 
information  of  business  or  strategic  significance  and  consists  of  a 
header  segment,  one  or  more  data  segments  in  a  specified  order, 
and  a  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  first  data  element  of  the  transaction  set  header 
segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard  format  and 
translating  them  to  the  star  lard. 

Version/Release 

Identifies  the  publication  of  the  standard  being  used  for  the  genera¬ 
tion  or  the  interpretation  of  data  in  the  X12  standard  format.  May 
be  found  in  the  Functional  Group  Header  Segment  (GS)  and  in  the 
Interchange  Control  Header  Segment  (ISA).  See  Control  Segment. 

VICS  Committee 

Voluntary  Interindustry  Communications  Standards  for  EDI. 

XU 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  EDI. 

X12.5 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic  inter¬ 
change  through  a  data  transmission,  and  it  provides  a  structure  to 
acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.6 

Application  Control  Structure.  This  standard  describes  the  control 
segments  used  to  envelop  loops  of  data  segments,  transaction  sets, 
and  groups  of  related  transaction  sets. 
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5.2  DoD  GLOSSARY 

AIS 

Automated  information  systems 
DUSD  (Logistics) 

Deputy  Under  Secretary  of  Defense  (Logistics) 

DES 

Data  encryption  standard 
DISA 

Defense  Information  Systems  Agency 
DLA 

Defense  Logistics  Agency 
ISA 

Interchange  control  header  identifier 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  identifier 
PLUS 

Protection  of  logistics  unclassified/sensitive  systems 
UN/EDIFACT 

EDIFACT;  electronic  data  interchange  for  administration,  com¬ 
merce,  and  transport 

USD  (A  &  T) 

Under  Secretary  of  Defense  for  Acquisition  and  Technology 
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